针对与webpack项目打包,我们正常做的最多的就是脚手架安装,后run build直接部署,不会去做过多的处理。 对webpack学习,使用webpack打包优化,主要注重两点 面向开发者:提示打包速度 面向用户:缩小打包体积 webpack 优化常用 打包速度优化 安装 speed-measure-webpack-plugin 来看下项目打包的速度。 除了工具还需要阅读代码,查看使用的插件在项目中的场景,综合考虑解决办法 打包体积优化 安装 webpack-bundle-analyzer 会弹出一个网页来显示项目打包后的体积大小,根据打包提及来优化 中将分的包排除出去 在项目打包的webpack配置文件中 plugins:[ new webpack.DllReferencePlugin({ context:path.resolve
由于运行在 Node.js 之上的 Webpack 是单线程模型的,所以Webpack 需要处理的事情需要一件一件的做,不能多件事一起做。 我们需要Webpack 能同一时间处理多个任务,发挥多核 CPU 电脑的威力,HappyPack 就能让 Webpack 做到这点,它把任务分解给多个子进程去并发的执行,子进程处理完后再把结果发送给主进程 HappyPack 对file-loader、url-loader 支持的不友好,所以不建议对该loader使用 安装 HappyPack npm i -D happypack 使用 HappyPack webpack.config.js 对应的参数 id:String 用唯一的标识符 id 来代表当前的 HappyPack 是用来处理一类特定的文件. loaders: Array 用法和 webpack Loader 配置中一样. threads verboseWhenProfiling: Boolean 开启webpack –profile ,仍然希望HappyPack产生输出。 debug: Boolean 启用debug 用于故障排查。
官网显示的这幅图很形象地描述了这个过程: webpack4相比于3做了很多优化,最大的改变就是支持了零配置打包,不再强制要求必须进行繁琐的webpack配置。 webpack4 针对不同的mode提供了不同的默认配置,这对于只希望配置打包出入口,不想深入了解其他配置的开发人员,提供了最基础的打包优化。 六、优化 到这里,我们项目已经能起来了,但是作为一名合格的程序猿,我们当然要探索更优实践。webpack有哪些常用的优化措施呢? 1、按需加载 webpack 提供了两种动态加载的语法。 否则会默认以id作为chunkName 2) 当bundle中已经以同步方式引入模块后,import()将不会再被webpack单独打包出js文件,可以认为是按需加载无效了 2、抽离公共模块 1)一般项目 为了合理利用浏览器缓存,一般会将不常变动的第三方库以及公共代码和业务代码分开打包 所以一般项目的打包策略为: 第三方库打包出vendor(基本不变) 引用两次以上的模块打包出common (变化较少)
webpack4相比于3做了很多优化,最大的改变就是支持了零配置打包,不再强制要求必须进行繁琐的webpack配置。 webpack4 新增了一个 mode 配置项。 webpack4 针对不同的mode提供了不同的默认配置,这对于只希望配置打包出入口,不想深入了解其他配置的开发人员,提供了最基础的打包优化。 首先我们看看项目的打包入口如何配置: webpack打包入口支持但入口和多入口,但入口文件只限于js文件(据说webpack5在考虑增加HTML文件和CSS文件作为入口)。 六、优化 到这里,我们项目已经能起来了,但是作为一名合格的程序猿,我们当然要探索更优实践。webpack有哪些常用的优化措施呢? 1、按需加载 webpack 提供了两种动态加载的语法。 ,一般会将不常变动的第三方库以及公共代码和业务代码分开打包 所以一般项目的打包策略为: 第三方库打包出vendor(基本不变) 引用两次以上的模块打包出common (变化较少) 业务代码 (常变) 对于分包方式
happyPack多线程打包 如何实现多线程打包? 安装happypack npm i happypack 改造webpack.config.js,实现多线程打包js let HappyPack = require('happypack'); id=js'//这个id=js就代表这是打包js的 } ] }, plugins:[ new HappyPack({这个id:js 就代表这是打包js的 id:'js',// use:[{//use是一个数组,这里写原先在rules的use里的loader配置 id=css'//这个id=css就代表这是打包css的 } ] }, plugins:[ new HappyPack({这个id
系列文章目录 ---- 通过wabpack.config.js实现打包 1. 刚开始要基本,开发模块,实现入口,出口打包 2. 后来实现html,抽离css文件输出打包输出 3. 正常实现es6转换es5 基本实现效果查看webpack官网达到实现效果 ---- 一、通过实现减少查找路径来实现优化? //某个路径 配置别名 优化 resolve: { alias: { "@": "", }, 二、通过多线程工作来优化 首先需要引入一包 happypack,在plugins happyThreadPool, //允许 HappyPack 输出日志 verbose: true, }), ] 三、通过平常咱写的代码中有引入未使用的情况下实现未使用的话就不打包来实现优化 new webpack.DllReferencePlugin({ context: __dirname, //判断后知晓那些文件不需要打包 manifest
使用插件webpack-spritesmith生成雪碧图 1、安装webpack-spritesmith; npm install --save-dev webpack-spritesmith 2.配置 webpack.config.js new SpritesmithPlugin({ //生成的雪碧图本身就压缩了图片大小 src: { 3、执行webpack打包指令,执行后打包生成dist/sprites/文件 4、index.html文件中引入sprite.css,如: <! DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>webpack</title> <link --测试webpack-->
通常情况下,maven打包结果为jar或war包。 而在生产环境部署项目时,却需要动态修改数据库配置等参数,此时如果仅仅打一个war进行部署,对于配置文件修改非常不方便。 那这里就提出2个问题: 第一,J2EE项目是否可以支持配置文件在war包之外? 第二,如何通过maven将项目文件进行统一打包压缩? Q1: 在J2EE项目中使用Spring框架时,可以将配置文件写在properties文件中,从外部加载相应配置参数。 testConnectionOnCheckin" value="${testConnectionOnCheckin}" /> 16 </bean> Q2: 通过maven插件maven-assembly-plugin将项目文件进行统一压缩打包 -- 部署打包: 通过maven-assembly插件压缩为tar包进行发布 --> 4 <plugin> 5 <artifactId>maven-assembly-plugin
前言 这是webpack打包优化【下】篇。前几篇针对性能要求高的项目从加快打包速度、减小资源体积方面入手,提出了一些优化政策,然后测试都可起到一定优化效果。本篇描述死代码的检测与去除。 基于这项特性webpack提供了tree shaking功能。这个功能便可以在打包过程中帮助我们检测没有被引用的模块,然后对这部分代码进行标记,并在资源压缩时将它们从最终的bundle中去掉。 使用压缩工具去除死代码 tree shaking本身只是为死代码添加上标记,而真正意义上去除死代码则是通过压缩工具来进行的,而此工具之前介绍过:terser-webpack-plugin。 小结 通过【上】【中】【下】三篇描述,介绍的一些打包优化的方案均可以对项目有不同程度的优化,无论是打包速度还是减小资源体积,都有涉及。 然而我们更需要清楚地了解到每一种优化策略都有其使用场景,并不是任何一个点放在一切项目中都有效。
前言 本篇介绍一些webpack优化的配置方法,目的有二: 打包速度更快 输出资源更小 “注意:在软件工程领域有一条十分重要的功能经验,不要过早优化。 在项目初期不要看到一个可以优化的点就去做优化,这样极有可能会增加尤其开发及维护的复杂度,并且从整体效果看,优化效果不会太理想。 1. 1.3 单个loader优化 以babel-loader为例: // 初始webpack.config.js module.exports = { // ... 这样一来,只有在发生变化时编译变化了的文件,对于整体而言也属于一种优化处理。 小结 本篇从多线程打包和缩小打包作用域两个方面入手,对webpack打包层面做出优化。 下一篇描述从动态链接库思想与死代码检测方面继续深入探究打包层面的深度优化。
前言 上篇从多线程打包和缩小打包作用域两个方面入手,对webpack打包层面做出优化。本篇描述从动态链接库思想方面继续深入探究打包层面的深度优化。 今天要介绍的主角“DLLPlugin”则借鉴了动态链接库的思路,对于第三方模块或者一些不常变化的模块预先进行编译和打包,然后再项目实际构建过程中直接取用。 3 链接到业务代码 试过之后,我们就要考虑将vendor链接到项目中去了。这里推荐与DLLPlugin配套的插件“DLLReferencePlugin”,它起到索引和链接作用。 在工程的webpack配置文件中(注意是webpack.config.js,不是vendor的配置文件),通过DLLReferencePlugin来获取刚才打包好的资源清单,然后在页面中添加vendor.js 下一篇介绍打包优化最后一个环节:死代码检测与去除。 ? 往期推荐 打包优化【上】 代码分片 样式文件分离
为什么要优化打包? 项目越做越大,依赖包越来越多,打包文件太大 单页面应用首页白屏时间长,用户体验差 我们的目的 减小打包后的文件大小 首页按需引入文件 优化 webpack 打包时间 优化方式 1、 按需加载 1.1 路由组件按需加载 5、代码压缩 UglifyJS: vue-cli 默认使用的压缩代码方式,它使用的是单线程压缩代码,打包时间较慢 ParallelUglifyPlugin: 开启多个子进程,把对多个文件压缩的工作分别给多个子进程去完成 随着项目越做越大,依赖的第三方 npm 包越来越多,构建之后的文件也会越来越大。 vue-cli已做的优化: 代码压缩,提取公共代码,再优化空间不大。 根据项目实际需要和自身开发水平选择优化方法,必须避免因为优化产生bug。
cmd,requirejs工具来写模块引用的代码,这些方便,也让我们很容易忽略一个问题,就是打包的产物的大小,当一个项目足够大时,我们的js甚至可以达到几MB到几十MB,所以,今天就来总结下关于减小构建产物体积 ,来达到减少首屏加载时间的内容 webpack 官方自带的优化策略 https://www.webpackjs.com/configuration/optimization/ 这里以react项目为例, .51cto.com/article/689344.html splitChunks: { chunks: 'async', // webpack 打包chunk分为 entry 上面的分包策略的理解注释中的内容提到了分包的条件和规则,那么,为了尽可能减小我们的主包的大小,我们就要尽可能减少在我们的 entry 选项中指定的入口文件中对其他模块的引用,或者使用异步模块引用的方式,常见的几个优化项目为 优化使用到的工具的引用,将必要的工具引用单独提到一个文件中,避免打包其他没用到的代码到主包 有些应用初始化相关但是跟主应用无关的代码,使用异步模块加载,如下 // app.ts (async () =
懒加载 webpack默认将所有js源代码打包成一个js文件,导致JS包会变得非常大,影响页面首次加载速度 按需加载能把不同路由对应的组件分割成不同的代码块,然后当路由被访问的时候才加载对应组件的js vue 默认不启用 Gzip 压缩,但我们知道,压缩后的文件体积会大大减少,这适用于线上部署。 安装 webpack 插件 npm install --save-dev compression-webpack-plugin@1.1.12 这样,你在 build 项目时,webpack 会帮你压缩文件 运行 npm run analyzer ,等待一会,就可以看到整个项目的打包情况了。 ? nginx配置一句话即可 nginx.conf文件 http{ ... gzip_static on; #静态压缩 ... } ? #3 验证 #3.1 打包 ? 虽然这两个文件的体积已经减少了不少,但是webpack还是提示文件big,还有待优化呀!!!
打包压缩js与css 由于webpack本身集成了UglifyJS插件(webpack.optimize.UglifyJsPlugin)来完成对JS与CSS的压缩混淆,无需引用额外的插件, 其命令webpack -p即表示调用UglifyJS来压缩代码,还有不少webpack插件如html-webpack-plugin也会默认使用UglifyJS。 打包合并html //使用插件extract-text-webpack-plugin打包独立的css //使用UglifyJsPlugin压缩代码 var HtmlWebpackPlugin = require warnings: false, //当删除没有用处的代码时,显示警告 loops: true //当do、while 、 for循环的判断条件可以确定是,对其进行优化 列几个压缩时常有的属性: dead_code -- 移除没被引用的代码 loops -- 当do、while 、 for循环的判断条件可以确定是,对其进行优化。
JS,我们需要用到uglifyjs-webpack-plugin,一个压缩JS的插件,没错,插件,plugins。 uglifyjs-webpack-plugin已经集成在webpack中,所以我们不用下载安装了,直接在config.js中引入: const uglify = require('uglifyjs-webpack-plugin 下面我们npm run build一下就打包成功了。JS压缩通常都是用在生产环境中的。下面来看看html文件是如何打包的。 html文件的打包需要用到另一个插件,html–webpack–plugin。 至此我们就学会了打包css,压缩js和打包生成html文件。
JS,我们需要用到uglifyjs-webpack-plugin,一个压缩JS的插件,没错,插件,plugins。 uglifyjs-webpack-plugin已经集成在webpack中,所以我们不用下载安装了,直接在config.js中引入: const uglify = require('uglifyjs-webpack-plugin 下面我们npm run build一下就打包成功了。JS压缩通常都是用在生产环境中的。下面来看看html文件是如何打包的。 html文件的打包需要用到另一个插件,html-webpack-plugin。 至此我们就学会了打包css,压缩js和打包生成html文件。
本文将从以下些许方面,对 Webpack 打包体积方面,做下优化探讨(备注: Webpack实践版本: 3.3.0): 定位 webpack 大的原因 这里推荐使用 webpack-bundle-analyzer 避免类库引而不用 倘若这类情况发生,对整个打包体积,不仅大而且亏。项目一旦大了,很难人为保证每个引入的类库,都被有用到,尤其是二次开发。 对待生产环境,压缩混淆可以很有效的减小包的体积;同时,如果能够移除使用比较频繁的 console,而不是简单的替换为空方法,也是精彩的一笔小优化。 在此也预告下一篇 《Webpack 打包优化之速度篇》,当然,此文也扔在完善中。 深圳.南山 @17-08-04. Last Modify 17-08-07 原文链接: Webpack 打包优化之体积篇
替换代码压缩工具 Webpack 默认提供的 UglifyJS 插件,由于采用单线程压缩,速度慢 ; webpack-parallel-uglify-plugin 插件可以并行运行 UglifyJS 插件 ,但并没有webpack-parallel-uglify-plugin效果好(可能因项目而异,在大家项目中可以使用对比)。 打包dll的时候,Webpack会将所有包含的库做一个索引,写在一个manifest文件中,而引用dll的代码(dll user)在打包的时候,只需要读取这个manifest文件,就可以了。 一、在项目build文件夹下新增文件webpack.dll.conf.js,内容如下 var path = require('path') var webpack = require('webpack' dll添加命令 "build:dll": "webpack --config build/webpack.dll.conf.js" 五、命令顺序 npm run build:dll //打包一次之后依赖库无变动不需要执行
在前文 Webpack 打包优化之体积篇中,对如何减小 Webpack 打包体积,做了些探讨;当然,那些法子对于打包速度的提升,也是大有裨益。 故而,合理的设置 include & exclude,将会极大地提升 Webpack 打包优化速度,比如像这样: module: { preLoaders: [ { test: [ext]') } } ] } 增强代码代码压缩工具 Webpack 默认提供的 UglifyJS 插件,由于采用单线程压缩,速度颇慢 ;推荐采用 webpack-parallel-uglify-plugin 打包优化之体积篇中提到,引入 DllPlugin 和 DllReferencePlugin 来提前构建一些第三方库,来优化 Webpack 打包。 于深圳.南山 @17-08-10 Last Modify: @17-08-13 如若转载,请保留原文链接: Webpack 打包优化之速度篇 ----